This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
Watching TV programs on Mobile terminals has been possible for a while now through a cellular network. The broadcast protocols as defined in DVB-H enhance the quality of service and the possibilities in term of business services. Mobile TV trials and first commercial activities focus on the classic live TV service.
A push file delivery service may be built on the top of a mobile broadcast network such as DVB-H and a bidirectional network such as the cellular 3G network. One advantage of a file based video delivery service is the relative flexibility over network issues such as bandwidth constraint and packet loss.
The push video on demand (VOD) service transmits video files over the broadcast multicast network (e.g. DVB-H) to an end-user device according to a smart scheduling based on a number of criteria that include among others priorities, user subscription, network status (measuring for instance bandwidth availability), dynamic content classification, schedule history. These files which match the user's preferences are saved to a local storage on the end-user device. This enables the user to access a wide variety of content without playback delay and with little concern for the underlying delivery mechanism. DVB-H is defined in the standards “ETSI EN 301 192 V1.4.1 (2004-11) Digital Video Broadcasting (DVB); DVB specification for data broadcasting” and “ETSI EN 302 304 V1.1.1 (2004-11) Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)”.
A mobile broadcast network is a unidirectional network where packet losses can be partially solved through the use of an application forward error correction (FEC). However using a FEC mechanism is bandwidth consuming and does not guarantee a fully recovered file. This is particularly true with a wireless mobile broadcast network where a terminal may miss large pieces of data when the user moves into poorly covered areas like tunnels. Moreover, in current DVB-H receiver implementations, according to the standard “ETSI TR 102 377 V1.1.1 (2005-02) Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines”, if a burst of packets that includes several IP packets cannot be entirely repaired using FEC, it is ignored. Several important IP packets may then be lost.
Another technique for avoiding packet loss consists in sending a same file several times. It may be well suited to short files like Electronic Service Guide containers as specified for example in the standard “DVB-IPDC ESG, ETSI TS 102 471 V1.2.1 (2006-09), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic Service Guide (ESG)”. But it is obviously a less efficient mechanism for video file delivery.
File repair or robust file casting is another method to guarantee the integrity of a video file transmitted over the air. It is especially well suited for a push VOD service enhancing the user viewing experience.
Post delivery file repair protocol is described in the standard “ETSI TS 102 472 V1.2.1 (2006-12), Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols” produced by the third Generation Partnership Project, Multimedia Broadcast Multicast Service group (3GPP-MBMS). It is also described in the standard “ETSI TS 126 346 V6.1.0 (2005-06), Universal Mobile Telecommunications System (UMTS); Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (3GPP TS 26.346 version 6.1.0 Release 6)” produced by the Digital Video Broadcasting-Convergence Broadcast Multicast System group (DVB-CBMS). The file repair mechanism is part of the so-called associated delivery procedures; the main procedure being file delivery based on the FLUTE protocol suite, specified in the RFC 3926—File Delivery over Unidirectional Transport (FLUTE). The goal of the file repair protocol is to provide a way to retrieve the missing packets and/or pieces of a file previously received according to the file delivery procedure.
The file repair procedure starts whenever a file is supposed to have been fully received. It is quite difficult in FLUTE to detect the end of a file. The last FLUTE packet of a file may be marked to signal the end of a file. However if this packet is missing, the receiver must rely on the File Delivery Table (FDT). The FDT is a set of information about files to be sent in band as part of the FLUTE protocol. Such information optionally contains the size of the file. Nevertheless DVB-CBMS, according to the RFC 3926, recommends using the FDT transfer length parameter that indicates the file size currently transported over the FLUTE protocol. Once the file is supposedly received, a receiver detects the missing FLUTE packets, establishes a connection with a repair server. According to a back-off algorithm, it sends one or more requests at the right time and gets the missing packets and saves the fully reconstituted file.
This mechanism can be combined with an application FEC like the raptor-code recommended by DVB-CBMS. The receiver requests only the packets necessary to run the FEC decoding process with success.
However the FDT may not be received by a receiver. Moreover, size information is present in the FLUTE packet header as a mandatory extension header gathering FEC delivery information including the transfer length. And it is not mandatory to deliver the header extension in each FLUTE packet. Finally, a watchdog timer may be used to securely close a file if none of the previous information has been detected by the receiver. It has to be used cautiously as the elapsed time between two packets is not constant.